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^: ABSTRACT 

H ! The AKARI All-Sky Catalogues are an important infrared astronomical database for next- 

"^ ' generation astronomy that take over the IRAS catalog. We have developed an online service, 

^ I AKARI Catalogue Archive Server (AKARI-CAS), for astronomers. The service includes useful 

and attractive search tools and visual tools. 

One of the new features of AKARI-CAS is cached SIMBAD/NED entries, which can match 
^ ' AKARI catalogs with other catalogs stored in SIMBAD or NED. To allow advanced queries 

lO ! to the databases, direct input of SQL is also supported. In those queries, fast dynamic cross- 

OO ' identification between registered catalogs is a remarkable feature. In addition, multiwavelength 

quick-look images are displayed in the visualization tools, which will increase the value of the 
service. 

In the construction of our service, we considered a wide variety of astronomers' requirements. 
As a result of our discussion, we concluded that supporting users' SQL submissions is the best 
solution for the requirements. Therefore, we implemented an RDBMS layer so that it covered 
important facilities including the whole processing of tables. We found that PostgreSQL is the 
best open-source RDBMS products for such purpose, and we wrote codes for both simple and 
^ ' advanced searches into the SQL stored functions. To implement such stored functions for fast 

Jh I radial search and cross-identification with minimum cost, we applied a simple technique that is 

not based on dividing celestial sphere such as HTM or HEALPix. In contrast, the Web application 
layer became compact, and was written in simple procedural PHP codes. In total, our system 
realizes cost-effective maintenance and enhancements. 

Subject headings: Data Analysis and Techniques 

1. Introduction not realistic for many astronomers to handle and 

analyze a number of catalogs in their local com- 

With the progress of technology, recent astro- p^^ers. Therefore, services to access the data via 

nomical surveys produce huge object catalogs: network have to be developed and could be used 

e.g., Sloan Digital Sky Survey (SDSS; [ York et al. | £pj. ^ ^^^^ variety of astronomers' requirements. 



2000|), Two Microri All Sky Survey (2MASS; j^ addition, it is desired that the services have 



Skrutskie et al. || 2006D. UKIRT Infrared Deep Sky application program interfaces (APIs) to devefop 

Survey (UKIDSS;|LawrenceeLalJl2007D, etc. It is 



services, since it is not efficient that all service 
providers have all observational data. 

In modern Web-based database solutions for 
object catalogs — for example, NASA/IPAC In 
frared Science Archive (IRSA; iBerriman et al 



l2000l ). VizieR (lOchsenbein et alll2000l) . and Vir 
tual Observatory (VO: ISzalavll200ll ) — portal sites 
are famous services. One of their common features 
is that we can use rich graphical user interfaces 
(GUIs) and a high-level programming interface 
based on VO standards for our various demands. 
On the other hand, one of the most advanced 



services, SkyServer of SDSS (iThakar et all 120041) . 
established a new basic model of a modern Web- 
based database solution for a huge catalog. Sky- 
Server provides not only basic search tools such 
as radial search but also advanced search tools 
such as the SQL search, CAS jobs, etc. Compared 
with the former services, SkyServer of SDSS is 
developed with focus on the availability of flexible 
SQL-based programming interface, rather than 
supporting rich GUIs and high-level interfaces. 
Such SQL-based programming interfaces will be- 
come very important for online services dedicated 
to long-life survey database, since astronomers of- 
ten need advanced search or their own programs 
to analyze catalogs and observational data for var- 
ious unique science themes. 

Our archive server AKARI-CAy^r has been 
developed to provide Web-based access tools for 
AKARI All-Sky Catalogues. The tools have been 
developed following the concept of SDSS Sky- 
Server, and users can search, match up, and 
browse stored data using the provided tools. In 
our service, there are tools based on our own ideas 
and implementation techniques. Reporting them 
in this article will be worthwhile information that 
is applicable to developments of future astronom- 
ical Web-based database systems. 

In this article, we mainly discuss the implemen- 
tation and design of a Web-based service for astro- 
nomical catalogs. In addition, our article will be 
helpful to develop basic search tools with mini- 
mum cost and to set up RDBMS security when 
the system allows users direct input of SQL state- 
ments. This article is organized as follows: In 



gl we briefly introduce AKARI All-Sky Cata- 
logues. In f|3l we describe an overview of our cata- 
log archive service. In §31 we discuss the basic di- 
rection of our technical design. Technical reports 
for RDBMS and Web application layers are given 
in fj5] and [J6l respectively. A summary is given in 

m 

2. AKARI All-Sky Catalogues Overview 



AKARI ( Murakami et all 12007 ) is the sec- 



ond Japanese space mission for infrared astron- 
omy, which has been developed by the Institute 
of Space and Astronautical Science (ISAS) at 
Japan Aerospace Exploration Agency (JAXA) 
and collaborators. The AKARI mission is an 
ambitious plan to make an all-sky survey with 
better sensitivity, higher spatial resolution, and 
wider wa velength coverage than those of IRAS 
(JHelou and Walken il98a) . AKARI is equipped 



with a telescope of 68.5 cm effective aperture and 
two instr uments: the Far-Infrared Surveyor (FIS; 
Kawada et al. 2007 ) for the far-infrared observa- 



^' AKARI-CAS has been developed based on open source 
softwares. If readers are interested in our system, we can 
show our source codes. Please contact us about them. 



tions and the Infrared Camera (IRC; lOnaka et al.l 
2007]) for the near and mid-infrared wavelengths. 
AKARI was launched by the M-V8 vehicle on 2006 
February 22. AKARI All-Sky Survey started in 
2006 May and was completed in 2007 August. 

AKARI All-Sky Catalogues are produced based 
on the obtained all-sky survey data. The public 
release of the first version of catalogs was made 
on 2010 March 30. This release consists of two 
infrared cat alogs: the FIS Bright Source Cata- 
logue (BSC; lYamamura et al.ll2010f ) with 427,071 
objects observed in the four far-infrared wave- 
length s, and the IRC Po int Source Catalogue 
(PSC; llshiharaet aLl l2010') including 870,973 ob- 
jects in the two mid-infrared wavelengths. The 
catalog set covers more than 98% of the sky. The 
information in the catalogs contains the object 
identifier, J2000 position, flux data, quality flags, 
and observational information. The catalog files 
can be obtained as a FITS file or a text format- 
ted file, and the release notes are also provided o 
There is no information for cross-identification be- 
tween FIS BSC objects and IRC PSC objects in 
the released catalogs. Note that image data of 
the AKARI All-Sky Survey are not yet publicly 



^'> See |http://www.ir.isas.jaxa.jp/AKARI/Observation/PSC/PubIic/| 
for details. 



released. 

3. AKARI Catalogue Archive Server 

AKARI Catalogue Archive Server (AKARI- 
CAS) provides basic tools for various astronom- 
ical studies with the AKARI catalogs. For the 
ground design of our service, we referred to the 
SDSS SkyServer and combined our new idea into 
it. Figure [T] shows the relation of AKARI-CAS 
Web tools and external services. The tool at the 
center of this figure is the object browser, Ex- 
plore Tool, that plays the leading role in our Web 
interface. Basically, hyperlinks to Explore Tool 
are created in all search results of AKARI-CAS, 
and Explore Tool dynamically prepa res hyperlinks 
to external sites, i.e., SIMBAElij ( Wenger et al. 



3. Third Reference Catalog of Brigh t Galaxies 
(RC3; Ide Vaucouleurs et al.|[T99lh 



2OOOI) . NEE© (|Helouet al.lll99lli . etc. It is pos 



sible to create a permalink to the Explore Tool 
by an object position. The links generated by ex- 
ternal services enable users to refer detail of an 
AKARI object. This design is essential to attain 
an interoperability feature of our Web interface. 

Figure [5] shows screenshots of the top page. Ex- 
plore Tool page, and SQL Search page, which sup- 
ports direct SQL input. It is important to note 
that the APIs of AKARI-CAS are open to the 
public. Both astronomer's scripts and Web service 
programs can call the APIs. Tools and documen- 
tation pages are arranged on the menu placed on 
the left side of Web pages. As shown in Figure 
m our Web tools are classified into two categories: 
Search Tools and Visual Tools. We briefly explain 
them in §3.21 and §3.31 after discussing stored data 
in §3.11 Our Web APIs are summarized in §3.41 

3.1. Stored Data 

We registered the AKARI catalogs and several 
external data that are expected to be important 
for astronomical studies into our databases. The 
data used through our Web tools are as follows: 

1. AKARI All-Sky Survey FIS Bright Source 
Catalogue (FIS BSC) version 1.0 

2. AKARI All-Sky Survey IRC Point Source 
Catalogue (IRC PSC) version 1.0 



^' See http://sinibad.u-strasbg.fr/sim bad/] 
■*' See http://nedwww.ipac.caltech.edu/] 



4. IRAS Point Source Catalog (IRAS PSC) 
version 2.1 

5. IRASFaint Source Catalog (IRAS FSC) ver- 
sion 2.0 

6. 2MASS Point Source Catalog (2MASS PSC) 

7. Cached object list of SIMBAD matched up 
with AKARI BSC/PSC objects 

8. Cached object list of NED matched up with 
AKARI BSC/PSC objects 

The cached SIMB AD/NED object list contains en- 
tries found around each AKARI object within a 
1.0' radius. The update of the cached list in the 
databases will be done every few months. 

3.2. Search Tools 

Search Tools consists of following tools to 
search AKARI catalogs with various criteria. Po- 
sitions (longitude, latitude) can be set by J2000, 
B1950, ecliptic or Galactic coordinates in all Web- 
based tools. 

1. The Radial Search tool provides an easy in- 
terface to search FIS and/or IRC objects 
within a radius of a position, which can spec- 
ifled by direct coordinate input or object 
name resolved by SIMBAD or NED. 

2. The Rectangular Search tool is used to 
search FIS and/or IRC objects inside a 
rectangle defined by two longitude, latitude 
pairs. 

3. The Cross-Identification tool provides an in- 
terface to search FIS and/or IRC objects 
with a user defined list of object positions. 
In the result, FIS objects and IRC objects 
are crossly identified. 

4. For the match up with SIMBAD/NED cat- 
alogs, the results of cross-identification be- 
tween AKARI objects and SIMBAD/NED 
objects were registered into CAS database. 
Users can easily obtain AKARI catalogs 
joined to cached catalogs obtained from 
SIMBAD/NED such as HD, MACHO, 2MASS, 



AKARI-CAS Search Tools 

Tools to search/match-up objects. 



External Services 



Radial Search 
result 




Explore Tool 
(object browser) 



list .php 



list -php 



ob j .php 



AKARI-CAS 
Visual Tools 

Tools to browse many images 
of multiple wavelengths. 



SDSS SkyServer 
Explore Tool 




Fig. 1. — Overview of page transitions of AKARI-CAS and other Web services. Links to Explore Tool are 
dynamically created in the results of Search Tools and Visual Tools. Explore Tool dynamically creates links 
to an external Web site by right ascension and Declination. Thus, users can visit various external sites for 
all searched objects and images via Explore Tool. The SDSS project team kindly updated their Explore 
Tool of SkyServer to append links to AKARI-CAS Explore Tool. 



NGC, SDSS, etc. Figure H shows the input 
and result display pages of this tool; the 
Henry Draper (HD) Catalogue is matched 
with AKARI FIS-BSC. 

5. With the SQL Search tool, users can di- 
rectly submit an SQL query to RDBMS of 
the AKARI-CAS using this tool. The SIM- 
BAD/NED cached data, RC3 catalog, IRAS 
catalogs and 2MASS PSC can be used in 
this tool. Users can perform fast cross- 
identification between AKARI catalogs and 
these catalogs. 

6. Access to the SQL Search is also possible 
from users' command-line programs. The 



Download Client-side Tools page provides 
the information for client-side utilities writ- 
ten in Python or Interactive Data Language 
(IDL) to perform an SQL search on the com- 
mand line. They can be included in users' 
programs for advanced analysis. Any user 
can download these client-side utilities from 
this page. 

3.3. Visual Tools 

Tools with quick-look images are categorized in 
Visual Tools. Supported quick-look images are 
currently SDSS, IRIS (Improved Reprocessing of 




EI H ^ D i^ 



Fig. 2.— Top page (top), SQL Search (left), and Explore Tool (right) of AKARI-CAS. The links to all 
tools and documentations are always displayed on the left side of all pages, except Explore Tool. Pages are 
categorized into Search Tools, Visual Tools, Database Documents, and Help. Displaying quick-look images 
of multiwavelengths and supporting direct input of an SQL statement are distinctive features of our service. 
Our service covers various demands from general users to power users. 



the /iJ^S" survey) If 2MASS, and DSS2. 

1. The Explore Tool page provides a useful in- 
terface to access catalog data of AKARI, 
RC3, IRAS and 2MASS, and quick-look im- 
ages. External links such as ADS, IRSA, 



SkyView|£P etc. are automatically generated 
on this page. Users can specify an object by 
its position, object name, or object identifi- 
cation number (ObjID). 

2. After uploading the position list, users can 



^^ Seejhttp://www.cita.utoronto.ca/~mamd/IRIS/| 



^' http://skyview.gsfc.nasa.gov/ 




Fig. 3.— Input form and a result of Match up with SIMBAD/NED tool of AKARI-CAS. With an easy GUI 
operation, users can obtain a list of any object catalogs in SIMBAD/NED joined with AKARI catalogs. 
This example shows the Henry Draper (HD) Catalogue joined with AKARI FIS BSC. 



view 40 quick-look images per page with Im- 
age List Tool. Links to the Explore Tool are 
also generated. This tool does not access any 
catalogs in our RDBMS. 

3.4. Web APIs 

Search Tools and Visual Tools have open Web 
APIs (GET or POST). Such APIs are important 
for not only astronomical study but also for soft- 
ware development. For example, the Herschel Ob- 
servation Planning Tool (HSpot) accesses our API 
of Radial Search via network and plots AKARI 
objects in the HSpot GUI. Explore Tool of SDSS 
SkyServer has two dynamic links to our Explore 
Tool after the update of 2010 April by the SDSS 
project team. The APIs with the GET method 



can be used as permalink. A URL to each query 
can be given as text in e-mails or in HTML doc- 
uments, which is useful for the users to communi- 
cate with the collaborators. 

Web programs in Search Tools return result ta- 
bles in HTML or text (CSV) format. A VO inter- 
face (e.g., VOTable, TAP, etc.) will be supported 
in the future. See Appendix A for more informa- 
tion on the APIs. 

4. Overview of Technical Design of CAS 

Our service shall be friendly for many levels of 
users, from beginners to expert users. In this sec- 
tion, we describe our direction of technical design 
for such requirements. 



4.1. Roles of RDBMS Layer and Web Ap- 
plication Layer 

When we develop a Web-based database sys- 
tem, we usually design two layers; RDBMS and 
Web application. The definition of the role of each 
layer is essential for our development, since the 
flexibility of service is almost determined by it. 

We expect that beginners want easy-to-use GUI 
tools, while expert users demand the direct access 
to databases. Moreover, if our tables have com- 
plicated relations, the SQL interface may be in- 
dispensable for advanced analysis. Therefore, it 
is unavoidable that our service accepts users SQL 
statements like SDSS SkyServer. In this case, we 
should prepare a couple of stored functions that 
execute SQL statements that are indispensable for 
typical searches and documents that press users 
for use of such functions, since users do not always 
have enough skill with RDBMS. Preparing some 
stored functions for astronomical studies such as 
conversion of coordinates between sexagesimal and 
degrees, etc., is helpful for users to submit SQL 
statements. 

After the preceding discussion, we define the 
role of each layer as follows: 

1. The RDBMS Layer covers the entire pro- 
cessing of tables, and conversion of coordi- 
nate and physical values. Codes for both 
simple and advanced searches are built-in 
SQL stored functions. Using stored func- 
tion, users can use SQL statements without 
knowledge about indices of tables. 

2. The role of the Web application layer is only 
to accept and check the users' input and to 
generate simple SQL statements. To sup- 
port the transmission of huge table data, this 
layer should not have any buffer to cache the 
data. To extend possibility of various appli- 
cations, we apply the stateless design to this 
layer. 

We expect that the preceding direction can also 
minimize the cost of maintenance of our service. 

4.2. Used Software Products 

We introduce the software products used to 
construct AKARI-CAS and explain why we choose 
them. 



In the RDBMS Layer, we employ PostgreSQL- 
8.4. As we described in glU our AKARLCAS 
allows direct input of SQL statement from users. 
It means that the RDBMS should have enough se- 
curity configuration system and high coding flexi- 
bility of stored functions in SQL, procedural lan- 
guage and C. It is known that some stored func- 
tions of SDSS SkyServer return multiple rows and 
are very useful to construct SQL statements for 
users. Therefore, our stored functions of RDBMS 
should be able to return multiple rows. In addi- 
tion, to construct the mirror site or to apply our 
codes to other projects flexibly, it is desirable that 
we use an open source RDBMS software. After 
our investigation of some RDBMS softwares, we 
found that PostgreSQL perfectly satisfies above 
requirements. 

We also use wcstools-S.aj* with PostgreSQL. To 
convert coordinates (e.g., from Galactic to J2000) 
in SQL statements, we wrote some stored func- 
tions in C and register them into our databases. 
The source codes in the stored functions call some 
routines of wcstools. 

In the Web application layer, we use PIIP-5.3. 
As explained in t j4.11 we expected that our im- 
plementation of Web application can be concise, 
since important facilities were built in the RDBMS 
layer. Therefore, we had flexibility in our selection 
of languages that can be used for the Web appli- 
cation and have libraries for accessing RDBMS. 
Perl CGI has been broadly used since more than 
10 years ago, however, Java/Tomcat and PHP be- 
come very popular for building Web application in 
recent years. 

According to our investigations about devel- 
opments of simple stateless Web applications at 
ISAS, we found two facts: 

1 . The efficiency of development in PHP is bet- 
ter than that in Java, since we do not have 
to compile our sources in PHP. 

2. PHP does not force us to use class, there- 
fore, we can rapidly write codes in procedu- 
ral style. 

We concluded that PHP is more suitable for 
our development, and confirmed that PHP appli- 
cations run fast enough compared with other Web 



^) http://tdc-www.harvard.edu/wcstools/ 



application platforms. 



5.2. Table Relationships 



5. Implementation of RDBMS layer 

The key features of our implementation are 
a number of kinds of stored function, fast ra- 
dial search, and cross-identification using index- 
ing that is not based on Hierarch ical Triangular 
Mes]B (HTM.lKunszt et al.l l200lh or HEALPi>|| 
( Gorski et al.l 120051 ) , and the security configura- 
tion for direct input of users SQL statements. We 
mainly explain these points in this section. 

5.1. Assignment of ObjIDs to Registered 
Catalogs 



We defined a unique number for each ob- 
ject of each catalog before registering them into 
databases. We named the numbers ObjID. Table 
[T]shows the current assignment rule of the ObjIDs. 

In Figure [TJ we show that Explore Tool is the 
main tool in our service. The dynamic links from 
the search result pages to Explore Tool are created 
using ObjIDs. Then, Explore Tool parses the Ob- 
jID in the arguments of the GET method, accesses 
the appropriate table, and displays required data. 

Using ObjID in links to Explore Tool, multiple 
arguments such as instrument, position, etc. in 
URL are not required in such links. 



*' See http://skyserver.org/HTM/ 
^' See http://healpix.jpl.nasa.gov/ 



Table 1: Assignment of objIDs to catalog objects. 
For example, objID = 200123456 is 123,456th ob- 
ject of the IRC catalog of version code 20. Note 
that this assignment might be changed. 



objID 


range of VV 


catalog 


VVxxxxxx 


01-49 


FIS catalog(s) 


VVxxxxxx 


50-99 


other AKARI-related catalogs 


VVxxxxxxx 


10-39 


IRC catalog 


VVxxxxxxx 


40-49 


external catalogs (large) 


VVxxxxxxx 


50-99 


2MASS PSC 


Ixxxxxxxxx 


- 


Reserved 


20XXXXXXXX 


- 


Reserved 


21VVXXXXXX 


01-46 


external catalogs (small) 



As we outlined in iJH we registered AKARI cat- 
alogs and other important data into our databases 
to support users' various demands. We show 
the relationships between the tables in Figure 
m The upper five tables shown in this figure 
are object catalogs, which have no information 
for cross-identification between catalogs. Such 
cross-identification is dynamically carried out us- 
ing stored functions. Details are described in ^^ 

On the other hand, SIMBAD/NED tables have 
static information of cross-identification. AKARI 
catalogs and cached SIMBAD/NED entries are 
easily joined to each other using JOIN or LEFT 
JOIN keywords. We also prepared some views such 
as SimbadCacheAU, NedCacheAU, etc. They are 
useful to join SIMBAD/NED information to the 
searched results of AKARI catalogs. Details of 
tables and views are given in our Database Docu- 
ment pages. 

5.3. Stored Functions 

We created variety of stored functions for our 
databases. They can be categorized as follows: 

1. String processing. 

2. Unit conversions of physical values such as 
AB magnitude and flux (in janskys). 

3. Conversion of coordinate between sexagesi- 
mal and degrees. 

4. Simple calculations of positional values such 
as separations between two positions. 

5. Low-level functions using wcstools routines. 

6. Stored functions that return multiple rows 
such as radial search, rectangular search, etc. 
They have indispensable SQL statements for 
users to run typical searches that heavily de- 
pend on the indices of the tables. 

Together with several built-in stored functions of 
PostgreSQL, various processing can be done in 
an SQL statement in our databases. Details are 
shown on our CAS document page. 

To implement the preceding stored functions, 
we used PL/pgSQL, C, and SQL from pro- 
vided languages in PostgreSQL. PL/pgSQL is 
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Fig. 4. — Relationships of the tables in AKARI-CAS RDBMS. The upper five table (object catalogs) have 
no information for cross-identification between catalogs; however, such cross-identification is dynamically 
done using an SQL statement with stored functions. 



a procedural language that is suitable to re- 
turn a value from numerical calculations and/or 
SQL executions and is typically used for func- 
tion 1-4 in our system. For example, SELECT 
fLonStr2Deg('12:02:00.00') returns 180.5 in 
degrees. 

Stored functions written in C call routines of 
wcstools, as shown in function 5. In addition, 
C is powerful enough to obtain better speed for 
performing a sequential scan with calculations in 
RDBMS. Some functions in function 4 are used 
with such a sequential scan. For example, we 
wrote fDistanceArcMinXYZO in C, which calcu- 
lates an angle between two objects. This stored 
function is frequently used in the radial search 
and is essential for system performance. Accord- 
ing to our test, we found that the radial search 
routine with fDistanceArcMinXYZO written in C 
performed double speed in several degrees, com- 
pared with that in PL/pgSQL. 



SQL is used for SQL executions, can return 
multiple rows|^ and is used for the function 6. 
For example, SELECT * FROM fGetNearbyObjEqCFis' , 
195 . 5 , 2.5, 40 . 0) returns the following result: 

objid ex cy cz distance 

3151469 -0.964260661127699 -0.261334534370321 0.0436536200906656 20.1372052103085 
3204984 -0.962002401977625 -0.267611949457189 0.0541776992590366 36.4431406886059 

This is a result of searching objects within 40.0" 
radius from (right ascension, declination) — 
(195.5, 2.5). Generally, the preceding result is 
used to join FIS object table or view with it. 

In total, about 2000 lines are newly written in 
PL/pgSQL, C, and SQL, including comments for 
our stored functions. 

5.4. Radial Search 

Radial search is the most typical query in the 
astronomical Web-based database services. How- 
ever, this search is somewhat unusual for RDBMS, 
and special methods to create a one-dimensional 



^^' Before creating a stored function that returns multiple 
rows, we have to register a new type. 



index (HTM and HEALPix) have been devised. 
We did not try such methods, but used a more 
cost-efFective method. 

The object tables in our databases have columns 
of unit vectors (ex, cy, and cz) presenting the 
J2000 source positions. In order to force the radial 
search to be fast enough, we created composite in- 
dices on all object tables, such as 

CREATE INDEX f isobjall_xyz ON FlsQbjAll (cx.cy.cz), 

and wrote stored fmictions that catch objects 
within a cube using index-scan and then drop ob- 
jects outside the strict search circle on the celestial 
sphere lllP 

We tested the performance on an Optcron2378 
(2.4GHz) PC and reached a result of less than 0.01 
s for a radial search of the IRC catalog within 20' 
radius from the Galactic center (177 objects are 
returned). More than 0.4 s was consumed without 
the index; therefore, the result demonstrated the 
usefulness of our method. Note that this test was 
made in the psql interactive terminal with the fol- 
lowing SQL statement: 

SELECT count (*) 

FROM fGetNearbyObj Gel ('ire' , 'gal', 0.0, 0.0, 20.0); 

after the \timing command. 

5.5. Cross-Identification between Regis- 
tered Catalogs 



As shown in t j5.21 tables of object catalogs do 
not have columns of ObjIDs of other catalogs. We 
created the f nameGetNearestObjIDEqO func- 
tion to get the ObjID of the nearest object from a 
given position in specified object catalog (name) 
by performing a radial search. For example, 
fIrcGetNearest0bjIDEq(180.67, 1.977, 1.0) 
searches the nearest object from the position 
(180.67, 1.977) within 1.0' in the IRC catalog. A 
cross-identification between registered catalogs is 
carried out by an SQL statement to repeat calling 
the stored function with appropriate arguments. 

The algorithm of the stored function is the 
same as that used in the radial search f H5.4p and 
has the great advantage of performing the cross- 
identification, since the cost of calculations be- 
fore executing an index scan for a radial search 



^^' In our tests, we have confirmed that this method is useful 
for radial search and cross-identification of huge catalogs 
such as 2MASS PSC. We will report the result in another 
article. 



is quite small compared with that based on tech- 
niques with dividing celestial sphere such as HTM 
or HEALPix. 

For example, the following SQL statement 
searches for FIS objects of fQuaL65 = 3 and joins 
the FIS search result with the IRC catalog: 
SELECT p.*, q.* 
FROM 
( 

SELECT * 

FROM FisObj 

WHERE fQual_65 = 3 

) P 

LEFT JOIN IrcObj q 

ON f IrcGetNearestObjIDEqCp.ra, p. dec, 1.0) 

= q.objID; 
In this case, the radius to match up objects be- 
tween the FIS and IRC catalogs is 1.0', which is set 
in the last argument of the f nameGetNearestObjIDEqO 
function. Some examples of SQL statements for 
cross-identification are given on the SQL Search 
page. 

In our test using a 2.4GHz Opteron PC, the 
elapsed time was 27 s to match up all FIS ob- 
jects with all IRC objects within a 15 " radius. 
This means that about 15,800 radial searches are 
processed per second. The following is the SQL 
statement for this search: 

SELECT coimtCf IrcGetNearestObjIDEqCra, dec, 0.25)) 
FROM fisobj; 

5.6. Cross-Identification between a Regis- 
tered Catalog and Users List 

To perform a cross-identification between a cat- 
alog table and the result of an SQL statement, 
we created a stored function using PL/pgSQL, 
f GetCrossIdResultEqO , which returns a table of 
results. 

The function fGetCrossIdResultEqO takes 
four arguments: 
fGetCrossIdResultEqCf is' , 

'SELECT * FROM upload', 3.0, false) 
The first argument is the name of catalog, the 
second one is an arbitrary SQL statement that 
returns multiple rows in the form of (id_x INT4, 
name_x: VARCHAR, ra_x FLOATS, dec_x FLOATS), 
the third one is the radius to search in arcminutes, 
and the last one is a flag to indicate the search 
scope: false means to search the nearest object 
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only, and true means to search all nearby objects. 

In the actual implementation of our cross- 
identification tool, uploaded users' position lists 
are converted into J2000 coordinates, and they are 
registered into a temporary table upload. Then 
f GetCrossIdResultEqO is called. In this case, 
the second argument should be 'SELECT * FROM 
upload' to scan a temporary table upload. An 
SQL statement to scan existing tables can also be 
set to the second argument o' 

The implementation of f GetCrossIdResultEqO 
is not complicated. After opening a cursoa^T for 
the J2000 position list returned from an SQL ex- 
ecution of the second argument, each position is 
scanned and fGetNearbyObjEqO is performed. 
The results of fGetNearbyObjEqO are pushed 
into a temporary buffer, and the function re- 
turns the buffer after closing the cursor. Thus, 
the code of f GetCrossIdResultEqO is a typical 
PL/pgSQL application. 

5.7. Security Configuration 

Built-in stored functions of PostgreSQL are so 
powerful that some of them can call low-level 
functions of the operating system. Therefore, we 
have to be careful with the security setup of the 
database before allowing the direct input of SQL 
statements by users. 

To configure the security setup, we have to un- 
derstand the concept of a schema of PostgreSQL. 
A schema of PostgreSQL is a section in which 
relations (tables and views) and functions exist. 
It is like a directory in which files are located in 
UNIX systems. Schemata pg_catalog and public 
are created in a new database by default. The 
pg_catalog schema has built-in relations and func- 
tions. Additional relations are registered into the 
public schema. 

PostgreSQL provides two users, postgres and 
public, by default. User postgres is the super-user, 
and public is the alias to all users. We appended 
admin user to create relations and functions and 
guest user to access the database from Web appli- 
cations. 

Just after creating a database, all users can cre- 



^^' However, our Web interface does not currently support 

such a use. 
^^' In PL/pgSQL, cursor moans a pointer to a row. 



ate functions and relations in the public schema 
and can use or access functions and relations in 
the pg_catalog schema. This is not secure at all 
for our purpose, and so we made a script to set up 
the right security configuration of our database. 
We show the permission of a database before and 
after running the script in Figure [H The permis- 
sion of the s symbol (i.e., tables and functions for 
our astronomical data) in Figure [5] is set by the 
admin user. See Appendix B for details of the 
script. 

Users input such as SQL statements should be 
tested in the Web application layer. Even if Web 
applications have vulnerability, the preceding con- 
figuration shall protect our database from mali- 
cious inputs. 

6. Implementation of Web Application 
layer 

Web application programs in AKARI-CAS 
are written in simple procedural PHP codes 
without object-oriented technique. Although 
PEAR::MDB2 and PEAR::HTTP_Request2 li- 
braries are used in our codes, we did not use any 
frameworks for PHP. In total, about 4300 lines 
are newly written in PHP including comments 
and HTML. 

We mainly explain some ideas to construct our 
Web application effectively in this section. 

6.1. Search across Multiple Catalogs 

Considering the future extension of services in 
ISAS/JAXA and other institutes, we implemented 
Radial Search and Rectangular Search of our ser- 
vice so that they can search the FIS and IRC cat- 
alogs simultaneously. 

PHP interface programs, xjradial.php for 
Radial Search and x_rect.php for Rectangular 
Search, have two operation modes. One is Single 
Search Mode, and the other is Multiple Search 
Mode. 

Single Search Mode takes a string parameter 
to specify a catalog such as catalog=fis, and 
outputs a result of selected catalog. Single Search 
Mode has an additional argument contents_only. 
When the argument contents_only=true is 
given, the PHP program does not return the full 
HTML contents (beginning <HTML>), but a part 
of HTML (HTML of the SQL command and table 
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Fig. 5. — Permission of database before and after running script for security configuration. Tlie letters R 
and RW indicate read-only and read- write permissions, respectively. The selected grant is set for S functions 
and relations. Our script runs under the postgres user and sets R, RW, and S permissions. The s permissions 
are set by owner of functions or relations. 



of results). This argument is used for Multiple 
Search Mode or future services. 

When checkboxes FIS and IRC are both se- 
lected (i.e., the URL has f is=true&irc=true) in 
the Radial Search or Rectangular Search pages, 
the PHP program x_radial.php or x_rect.php 
works in Multiple Search Mode. It forwards 
the HTTP request to the Single Search Mode 
of the same program of the local host with a 
contents_only=true argument for each catalog. 
The results are returned to the program of Multi- 
ple Search Mode, which attaches the header and 
footer and outputs into the HTTP stream. That 
is, Multiple Search Mode and Single Search Mode 
are, in fact, realized by the same program, and 
the Multiple Search Mode works like a wrapper 
program. 

Thus, an option to output a part of HTML 
is useful to build a tool to search a number of 
catalogs simultaneously. It is very easy to build 
a Web application that unifies a number of re- 
sults of radial and rectangular searches on differ- 
ent serverso' If such a tiny technique is used uni- 
versally, we will be able to easily create extensive 
services without having many catalog data at a 
datacenter. 

6.2. Using Images of SkyServer and Sky View 
in Our CAS 

Our Explore Tool and Image List Tool provide 
quick-look images in multiwavelengths. Although 
image products from AKARI All-Sky Survey are 



not available now, images of SDSS, IRIS, 2MASS, 
and DSS2 are displayed in them. These images 
are not stored in our local server, but in the SDSS 
SkyServer and Sky View. 

To inlay the quick-look images into our tools, 
the PHP programs obj.php and list.php dy- 
namically generate <img src= ... /> tags so that 
users' browsers display the images after down- 
loading them. SkyServer provides a Web API to 
obtain a color JPEG image directly using a single 
GET method request; therefore, there is no re- 
quirement of additional programs to inlay them. 
On the other hand. Sky View does not provide such 
a Web API with a single GET method to get a 
color imaged So we created a wrapper program 
to obtain a color JPEG image using a single GET 
method request. This is an example of the URL: 

http: //darts . isas .jaxa.jp/ir/akari/cas/ 
getskyview.php?survey=DSS2+IRy.2CDSS2+Red7,2 
CDSS2+Blue&rgb=t&position=182 . 047113967.202 
. 87884015&scale=0 . 000277777777777778&pixel 
s=200y.2C200&grid=J2000&gridlabels=l 

To create Web-based visual tools easily, it is 
very important for servers to provide open Web 
APIs with a single GET method request to obtain 
a color image directly in the format supported by 
the browsers. If such services appear universally, 
we will be able to create attractive visual tools 
without having a huge amount of imaging data at 
each datacenter. This concept is common for such 
visual tools and search tools of multiple catalogs, 
as described in %.![ 



^'*' Note that links in HTML contents should be absolute 
URLs for such a purpose. 



^^' There exists an API with a single GET method for a 
single-band image. 
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<? 



$db = "DRl"; 

$format = "text"; 

$cmd = $argv[l]; /* Obtain SQL statement from command- line args */ 

/* Create URL */ 

$url = "http: //darts . isas. jaxa. jp/ir/akari/cas/tools/search/x_sql .php?" ; 

$prms = array ( 'db' => $db, 

'format' => $format, 

'cmd' => $cmd 

); 

/* Access to AKARI-CAS */ 

$fp = fopen($url . http_build_query($prms) , "r"); 

if ( $fp === false ) { 

fputsCSTDERR, "ERROR: fopenO failed\n"); 

exit (1) ; 
> 

/* Read returned catalog data */ 
/* Store the column nsunes */ 
if ( ($s=fgets($fp)) !== false ) { 

$col_naines = explode (",", rtrim($s)); 
> 

/* Store the values to an associative array and display them */ 
while ( ($s=fgets($fp)) ! == false ) { 

$col_vals = arrayO ; 

$v = explodeC",", rtrim($s)); 

for ( $i=0 ; $i < count ($v) ; $i++ ) $col_vals [$col_names [$i] ] = $v[$i]; 

print_r ($col_vals) ; 
> 
f close ($fp) ; 



?> 



Fig. 6. — Example PHP code to access SQL Search of AKARI-CAS. To use this program, an SQL statement 
is set to first argument of the command Hne for executing this script. 



6.3. Client-Side Tools for SQL Search on 
Command-Line 

Server program x_sql . php for SQL Search 
has interfaces of both POST and GET. The 
POST version is used for input from a brovirser, 
and the GET version is used for command-line 
tools. The client-side tools can simply send 
a single GET method request to x_sql . php 
and receive returned results. Therefore, users 
can access SQL Search with command-based 
HTTP clients such as wget or curl. On PHP, 
using fopenO or f ile_get_contents () with 
http_build_query() is the most useful way to 
send their request to 'SQL Search'. See Figure H] 
for an example PHP code. 



AKARI-GAS provides two kinds of client-side 
tools that enable direct access to the database 
from users' local computers. One is sqlcLakari.pjO^ 
written in Python; sqlcLakari.py can be used by 
itself from UNIX command shells or from users' 
scripts. Another tool is queryakari.pro written in 
IDL. It is written as an IDL function that submits 
an SQL command to AKARI-CAS. The query 
results are returned as an array of an IDL anony- 
mous structure, whose tags are the same as the 
column names of the query results. This allows 
users to easily add the querying functionality to 
the CAS to one's own IDL programs. 



^^'' Original code (sqicl.py) was written by T. Budavari, who 
gave us permission to modify and re-distribute his program. 
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7. Summary 

We developed AKARI Catalogue Archive Server 
(AKARI-CAS) to provide basic tools to access 
AKARI-related catalogs for various studies. Our 
tools have been developed following the concept 
of SDSS SkyServer, and users can search, match 
up, and browse stored data using our attractive 
tools. 

We discussed our direction of implementation 
for our service that supports many levels of users. 
We concluded that the whole processing of tables 
should be implemented into an RDBMS layer. We 
found that PostgreSQL is the best open-source 
RDBMS product for our requirements, and we de- 
veloped various facilities using stored functions of 
PL/pgSQL, C, and SQL in the database. In con- 
trast, the Web application layer became compact; 
this minimizes the cost of maintenance in the long 
term. 

We presented our simple techniques without 
HTM or HEALPix to perform fast radial search 
and dynamic cross-identification using RDBMS. 
With our report of the security configuration of 
PostgreSQL, the information in this article will be 
helpful to develop future astronomical Web-based 
database systems. In the development of the Web 
application, we showed our idea to create extensive 
services using only standard technology and with- 
out having a huge amount of data at a datacenter. 
Some thought put into the definition of Web APIs 
and public release of the APIs can increase the 
possibility of online astronomical services. 
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Appendix A: Basic concepts and notes of 
the AKARI-CAS Web API 

AKARI-CAS employs stateless design and de- 
fines Web API. An API returns a search result in 
HTML or text format. Input parameters are basi- 
cally taken with the GET method of HTTP pro- 
tocol; however, the POST method is also applied, 
as required by some tools. 

To search catalogs or images, users set their 
search conditions on the arguments of APIs. In 
typical use with Radial Search or Explore, af- 
ter setting the catalog parameter to choose a 
catalog, positional values such as longitude and 
latitude can be set on Ion and lat parameters 
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in degrees or sexagesimal. The coordinate sys- 
tem of Ion and lat parameters can be selected 
by the coordinate parameter; j2000, bl950, 
ecliptic, and galactic are supported. Instead 
of position, users can input an object name that 
can be resolved by SIMBAD or NED with the 
ident_simbad or ident_ned parameters, respec- 
tively. In some parameters. Boolean values should 
be set in true/false or 1/0. 

All APIs use the db parameter to select the 
database that users want to use. A database only 
has a version of a catalog set; for example, the DRl 
database has FIS version 1.0 and IRC version 1.0 
catalogs. 

APIs for the table output support display of 
the column types (e.g., int4, bpchar, etc.) in 
the table header. To enable this feature, use the 
types=true argument. This is useful to create 
users' programs in certain languages. The output 
format of a table is HTML or text in these tools. 
Users can choose delimiter and newline characters 
in the text format with delimiter and newline 
parameters. 

We will keep our Web API simple. To perform 
a search with a complicated condition, users can 
learn SQL with our SQL Tutorial page and use the 
API of SQL Search. 

See the Web API page in the Help category of 
our AKARI-CAS for more information. 

Appendix B: Security Configuration of 
PostgreSQL 

We show step-by-step procedures in the script 
described in i J5.7l for security configuration of Post- 
greSQL in the AKARLCAS: 

1 . Revoke permission of all schemata from pub- 
lic user: 

REVOKE ALL ON SCHEMA public from public; 
REVOKE ALL ON SCHEMA pg_catalog from public; 

2. Grant permission of all schemata from ad- 
min user: 

GRANT ALL ON SCHEMA public to admin; 
GRANT ALL ON SCHEMA pg_catalog to admin; 

3. Create guest schema: 
CREATE SCHEMA guest; 



4. Grant read-only permission of all schemata 
to guest user: 

REVOKE ALL ON SCHEMA guest from guest; 
REVOKE ALL ON SCHEMA public from guest; 
REVOKE ALL ON SCHEMA pg_catalog from guest; 
GRANT USAGE ON SCHEMA guest to guest; 
GRANT USAGE ON SCHEMA public to guest; 
GRANT USAGE ON SCHEMA pg_ catalog to guest; 

5. Revoke permission of all relations in pg_catalog 
schema from public user: 

REVOKE ALL ON pg.all FROM public; 

6. Grant permission of all relations in pg_catalog 
schema to admin user: 

GRANT SELECT ON pg_all TO admin; 

7. Grant permission of pg_type to guest user: 

GRANT SELECT ON pg.type TO guest; 

This is required to access type information 
of returned result of an SQL execution from 
Web apphcations. 

8. Revoke permission of all functions in pg_catalog 
schema from public user: 

REVOKE ALL ON all( ... ) FROM public; 

9. Grant permission of all functions in pg_catalog 
schema to admin user: 

GRANT ALL ON alK ... ) TO admin; 

10. Grant permission of selected functions in 
pg_catalog schema to guest user: 

GRANT EXECUTE 01} selectedi ... ) TO guest; 

We have to select functions carefully. 
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